home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0559.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.7 KB  |  99 lines
  1.  
  2. >  Date: Fri, 08 Jan 93 13:57:32 CST
  3. >  From: Dan Connolly <connolly@pixel.convex.com>
  4. >  
  5.  
  6. >  This question seems to confuse two things: the ISOlat1 entity
  7. >  set, and the ISO Latin 1 character set. The first is mapping
  8. >  of names to glyphs, and the second is a mapping from the numbers
  9. >  128-255 to glyphs. I think they're in alphabetical order
  10. >  by name, but not in order by the ISO Latin 1 character set.
  11.  
  12. I think we should specify ISO latin 1 as the base set.  I think that  
  13. a lot of people in the nordic countries use it routinely and they
  14. will go crazy if they have to use overload the crurly brackets again
  15. as they have to with mail.
  16.  
  17. Therefore, we should allow those people who have 8-bit capability to
  18. just stick in 8-bit codes.  Admitedly I thought the ISO world kept to
  19. the codes 21-7E and A1-FE hex for G0 and G1 graphics sets, using the  
  20. others for control sets (C0 and C1). Maybe ISO Lantin 1 has nothing  
  21. to do with ISO 8 bit extensions. Sorry I can't quote ISO numbers.
  22. But whatever is common usage, let us have an 8 bit set.
  23.  
  24. (Anybody illuminate us on this?  Anybody got the ISO Latin 1  
  25. character set listing by number?)
  26.  
  27. Now for died in the wool 7-bit hackers, is it fair to requier them to  
  28. remember numbers, or would it be nicer to allow them to put in
  29. codes using entity names?  Some people would I am sure like the  
  30. latter, but it is NOT important because we are aiming for wysiwyg  
  31. editors and so would regard human-readable character names as a  
  32. temporary thing anyway.
  33.  
  34.  
  35. >  Here is the crux of the matter:
  36. >  
  37.  
  38. >  >The communication between it and the text object would have to be  
  39. defined in  
  40.  
  41. >  >terms of a particular character set
  42. >  
  43.  
  44. >  And this character set is stated in the SGML declaration at
  45. >  the top of html.dtd.
  46.  
  47. No - that is something different. In the top of the DTD is specified  
  48. the reference base set for the DTD itself and SGML documents.
  49. The interface between two software modules is something else and can  
  50. be independent of that.
  51.  
  52. >  If we define HTML in terms of the
  53. >  full ISO Latin 1 character set, then the parser can deal with
  54. >  ö, and pass it to the text object as a data character, just
  55. >  like an 'A' character. For X displays using iso8559 fonts, that's
  56. >  cool.
  57.  
  58.  
  59. Sorry, is iso8559  = Iso latin 1?  (I have no head for numbers >1 :-)
  60.  
  61. yes it is cool. Use Midas or Viola to look at the Hyper-G stuff and  
  62. it works very nicely.
  63.  
  64. >  But on a PC or a Mac, that means the text object will have to
  65. >  scan all the data it gets and convert the Latin1 encoding to
  66. >  it's own. Yuck.
  67.  
  68. Yup. Big deal?  Not really. Just a set of parallel tables.  Peter  
  69. Flynn of the CURIA project is producing a lot of archived gaelic and  
  70. is currently dealing with a requirement for a line-mode browser which  
  71. can switch its characetr set depending on the terminal emulator the  
  72. reader is using.
  73.  
  74. Problems only occur if there are characters which can't be mapped 1-1  
  75. to the local set, and must be represented by more than one character  
  76. (like uumlaut -> ue, ae dipthong -> ae etc) AND you can edit, in  
  77. which case the original form must be preserved. In this case, passing  
  78. on of the entity is essential.  But doing it for every character >127  
  79. would be a pain memorywise. So I would suggest that a configuable  
  80. table define which entities can be crunched down to a single  
  81. character in the local representation and the rest be passed on from  
  82. the SGML parser to the SGML app as external entities.
  83.  
  84. >  >... and perhaps if there is more than one  
  85.  
  86. >  >contender the SGML engine could have a compilation option.
  87. >  
  88.  
  89. >  Hmmm... One might argue that as long as we support conversion  
  90. inside
  91. >  the SGML parser for EBCDIC machines, we might as well support PC  
  92. and
  93. >  Mac character sets while we're at it.
  94.  
  95. Yes.
  96.  
  97. Tim
  98.  
  99.